Implementing Edge Transport Server
The Edge Transport server
role in Exchange Server 2010 provides a secure SMTP gateway for all
incoming and outgoing e-mail in an organization. As an SMTP gateway,
the Edge Transport server's primary role is to maintain message
hygiene, which includes anti-spam and antivirus filtering. You also can
use the Edge Transport server to apply messaging policies to messages
that are sent to the Internet.
When planning to deploy Edge Transport servers, consider the following factors:
You cannot
install the Edge Transport server role along with any other Exchange
Server 2010 server role. The Edge Transport functions require a very
separate level of security and must be separated from your Exchange
organization. To provide increased security, you must install the Edge
Transport server role on a separate computer, which can be virtual or
physical.
Edge
Transport servers should be installed in the perimeter network and
should be physically secure and well separated from servers in the
internal network.
The computer should not be a member of an internal Active Directory domain.
Note: You
should not install the Edge Transport server role on a computer that is
a member of the internal Active Directory domain, but you can install
it in a perimeter Active Directory forest. Microsoft IT and other large
companies have a dedicated Active Directory domain for servers in the
perimeter network. This makes security updates and other
maintenance/management easier than when you're dealing with
non-domain-joined computers.
1. Considering Firewall Ports
Because the Edge
Transport server role is installed in a perimeter network and thus is
directly connected to the Internet, you should also plan to place a
firewall between the Internet and your Edge Transport server to
increase protection. This firewall should be configured to open certain
ports.
This section is about
what network ports you should open in the firewall that is between the
Internet and the perimeter network (external) and the perimeter network
and the internal corporate LAN (internal), as described in Table 1.
You can take this as the minimum number of ports you should open, but
remember that you can also configure the Edge Transport to use network
ports other than those listed here.
The table includes only the Edge Transport server role.
Table 1. Firewall Ports Required for Edge Transport Server Role
FIREWALL DIRECTION | FIREWALL RULE | DESCRIPTION |
---|
External | Allow port 25 from all external IP addresses to the Edge Transport server. | Enables SMTP hosts on the Internet to send SMTP messages to this server. |
External | Allow port 25 to all external IP addresses from the Edge Transport server. | Enables the Edge Transport server to send SMTP messages to the Internet. |
External | Allow port 53 to all external IP addresses from the Edge Transport server. | Enables the server to resolve Domain Name System (DNS) names on the Internet. |
Internal | Allow port 25 from the Edge Transport server to specified Hub Transport servers. | Enables the transmission of inbound SMTP messages onward to internal Hub Transport servers. |
Internal | Allow port 25 from specified Hub Transport servers to the Edge Transport server. | Enables the transmission of outbound SMTP messages from internal Hub Transport to the Edge Transport server. |
Internal | Allow
port 50636 for secure Lightweight Directory Access Protocol (LDAP) from
Hub Transport servers that participate in EdgeSync to the Edge Transport server. | Enables the Hub Transport server to replicate directory information to the Edge Transport servers using Edge Synchronization. |
Internal | Allow port 3389 for Remote Desktop Protocol (RDP) from the internal network to the Edge Transport server. | Enables remote desktop administration of the Edge Transport server (recommended). |
Henrik Walther
Technology Architect, Timengo Consulting, Copenhagen Denmark
Microsoft Forefront Threat Management Gateway (TMG), Microsoft's application
layer firewall solution, and Exchange 2010 Edge Transport role can now
be installed together on the same computer. This is especially an
attractive configuration for SMORGs (small and medium organizations)
that are bound by a limited IT budget. Even though Microsoft ISA 2006
is supported with Exchange 2010, Microsoft recommends using Forefront
TMG to prevent configuration issues. You also cannot install Edge
Transport and Microsoft ISA 2006 on the same computer because ISA 2006
does not support 64-bit operating systems.
If you plan to use
Microsoft ISA or Forefront TMG to separate Edge Transport and Hub
Transport server roles, you need to remember either to add Exchange
SMTP verb commands to the SMTP add-in filter or to disable the filter
altogether. You can find the details at http://technet.microsoft.com/en-us/library/bb851514(EXCHG.80).aspx.
|
2. Planning and Configuring Edge Synchronization
The Edge Transport server
does not use Active Directory to store its configuration information;
instead, Edge Transport servers use Active Directory Lightweight Directory Services (AD LDS) to store this data. AD LDS is the successor of Active Directory Application Mode (ADAM), a service that was available in Windows Server 2003.
2.1. About AD LDS
AD LDS is a special mode
of the AD DS that stores information for directory-enabled
applications. AD LDS is an LDAP-compatible directory service that runs
on servers running the Windows Server 2008 or Windows Server 2008 R2
operating system. AD LDS is designed to be a stand-alone
directory service. It does not require the deployment of DNS, domains,
or domain controllers; instead, it stores and replicates only
application-related information.
Before you can install the Edge Transport server role, you must install the AD LDS server role on the same Windows Server 2008 computer that will host the Edge Transport role. This is because AD LDS stores configuration data for your Edge
Transport server role. During Exchange installation, AD LDS is then
configured automatically. The following types of information are stored
in AD LDS:
Schema
Configuration
Recipient information
The AD LDS database is stored in the <Exchange_Install_Path>\TransportRoles\data\Adam directory.
Note: The
AD LDS stores configuration and recipient information. The Queue
database also exists on every Edge Transport to store message queues.
The AD LDS instance does not need much administration because all the information that it contains is synchronized using Edge synchronization from the Active
Directory instance that holds all of the Exchange organizational
configuration data and information about mail-enabled objects. Even if
the database is lost, you just start EdgeSync again and the database will be newly created.
However, always
consider that the database does not include all configurations and
settings, so it is best practice to back up the Edge server
configuration using the ExportEdgeConfig.ps1 script.
2.2. Edge Synchronization
Edge synchronization,
or EdgeSync, is a process that replicates information from your
internal Active Directory to the AD LDS located on the Edge Transport
server.
Because Edge Transport
servers are not joined to the internal Active Directory domain, they
cannot directly access the configuration or recipient information that
is stored in Active Directory.
You can deploy Edge
Transport servers without using EdgeSync, but using EdgeSync can
decrease the effort needed to administer the Edge Transport servers.
Active Directory contains much of the configuration information
required by the Edge Transport server. For example, if you configure
accepted domains in Exchange Management Console for all Hub Transport
servers centrally, these accepted domains are replicated automatically
using EdgeSync to the Edge Transport servers. Every Edge Transport server needs its own Edge Subscription to synchronize with Active Directory.
To enable any filtering or transport rules that are based on recipients, you must implement EdgeSync to replicate the recipient information to AD LDS.
2.2.1. EdgeSync Replication
After you enable Edge Synchronization, the EdgeSync process establishes a point of synchronization between one Hub Transport server in the Active Directory site that was selected and the Edge Transport server, and synchronizes configuration and recipient information between Active Directory and AD LDS.
Even though EdgeSync is
very similar to Exchange Server 2007, in Exchange 2010 EdgeSync keeps
track of synchronized information and only synchronizes the changes
since the last replication cycle. Of course, this is much more
efficient than EdgeSync in Exchange 2007.
Note: Only
the internal Hub Transport servers, not the Edge Transport servers,
initiate EdgeSync replication. EdgeSync replication traffic is always
encrypted using Secure LDAP.
During synchronization, EdgeSync replicates the following data:
Accepted domains
Send connectors
Hub Transport servers list (for dynamic connector generation)
Recipients (one-way hashed)
Safe senders, safe recipients, and blocked senders (one-way hashed)
Domain Secure List (such as the TLSSendDomainSecureList and TLSReceiveDomainSecureList properties)
Note: All
options that are synchronized by EdgeSync are managed in Active
Directory, so you can no longer change them on the Edge Transport
server. You need to change them using EMC or EMS connected to your
internal Exchange organization and allow EdgeSync to transfer the
configuration settings to the Edge Transport servers.
Some configuration settings
have to be made on the Edge Transport server role level because these
configurations are not replicated using EdgeSync. The following list
includes all areas that you need to configure for every Edge Transport
server or use Edge Transport cloning to share a single configuration
between all Edge Transport servers:
All Edge Transport server settings (external or internal DNS Lookups, Log Settings, Limits, and so on)
Exchange Product Key
Anti-spam settings
Receive connectors
Transport rules
Digital Certificates and Exchange services enabling digital certificates to secure communications
2.2.2. How does EdgeSync Work
To establish Edge Synchronization between an Edge Transport and Hub Transport server, you need to follow these steps:
Create an Edge subscription file on Edge Transport.
Import an Edge subscription file on Hub Transport.
Start and verify the EdgeSync Process.
Create an Edge subscription file on Edge Transport
If you want to perform EdgeSync on your Edge Transport server, you should consider the following areas before creating the Edge subscription file:
An Edge Transport server needs a fully qualified domain name (FQDN) configured.
You must register the FQDN with your DNS server.
The FQDN must be resolvable and reachable from the Hub Transport servers in the site where you add the Edge subscription file.
EdgeSync
and the Connectors use the computer certificate of the Edge Transport
server, so make sure you've already installed the correct certificate
(for example, that supports TLS if required).
Note: The
hub server must be able to communicate with the Edge Transport server
using the FQDN as defined in the Edge Subscription file! Remember, by
default the Firewall on the Edge Transport server refuses a PING
response!
You create an Edge subscription file by using the New-EdgeSubscription
cmdlet in EMS started with Run as Administrator. The default EMS will
not provide sufficient permissions to create an edge subscription. This
will create an XML file, as shown in Figure 7-1.
As you can see, the sample
Edge subscription file includes certain information such as the Edge
servers' FQDN, the Edge server's public certificate, the default SSL
port that is used for AD
LDS, and the server's Exchange version. You have to use the Edge
subscription file on a Hub Transport server within 1,440 minutes or the
XML will expire.
Note: The
Edge Transport server isn't limited by version control (like Hub
Transport or UM server role), meaning you can subscribe an Exchange
2010 Edge Transport server to an Exchange 2007 Hub Transport server
just fine. You just won't benefit from incremental EdgeSync. You can
also have an Exchange 2007 Edge Transport server in front of an
Exchange 2010 Hub Transport server.
Import Edge subscription file on Hub Transport
After you create the Edge subscription file, you need to copy it to a Hub Transport in the Active Directory site that you want to link the Edge Transport server to. On the Hub Transport server, use the New-EdgeSubscription cmdlet to import the Edge subscription file.
Be aware that you cannot pass the filename directly to the cmdlet—you need to pass the data string, as shown in Figure 2.
This is because of remote Windows PowerShell. Since the script is not
running locally, you can't give a local path but have to pass the file
data in the cmdlet.
Start and Verify the EdgeSync Process
After the Edge subscription file is imported to the Exchange configuration, the EdgeSync replication process starts automatically. The default port for synchronization is port 50636 as defined in the Edge subscription file.
To change the default EdgeSync communication port you can use the ConfigureAdam.ps1 script located in the <Exchange_Install_Path>\Scripts folder. For example, if you want to change the communication port to 50222, run .\ConfigureAdam.ps1 –Sslport:50222 with EMS.
The first Hub Transport in the Active
Directory site where you created the Edge subscription that notices the
subscription seizes the lease and will use the Microsoft Exchange
EdgeSync service to start the synchronization with the Edge
Transport server. This Hub Transport server will keep the lease until
it goes offline or is otherwise unable to service the subscription
which will then result in the next Hub Transport available in the
Active Directory site seizes the lease.
If you like to force immediate replication, you can use the Start-EdgeSynchronization – TargetServer <EdgeTransportName> -Server <HubTransportName> cmdlet, which will trigger the replication and show you some information about recent changes in Active Directory.
Note: You can use the Windows LDP client to look at the AD
LDS database on the Edge Transport server by connecting to port 50389.
Even though most entries are encrypted, you can check that replication
is working.
Alternatively you can make sure that the EdgeSync process finished successfully by running the Test-EdgeSynchronization –FullCompareMode
cmdlet on a Hub Transport server in the connected Active Directory site
that will compare Active Directory with the AD LDS on all Edge servers
that are subscribed to the Active Directory site to make sure they are
synchronized correctly. You will receive detailed information as
output, as shown in Figure 3.